Qodo reviews are paused for this user.

Troubleshooting steps vary by plan Learn more →

On a Teams plan?
Reviews resume once this user has a paid seat and their Git account is linked in Qodo.
Link Git account →

Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center?
These require an Enterprise plan - Contact us
Contact us →

再补一个实质问题：

现在 makeLoadExternalStats 用的是 GetRowSizeFromTableDef(tableDef, true) * 0.8 来估算 file-based LOAD 的 rowSize，但在 LOAD DATA ... (col, @var, ...) 这条路径里，传进去的 tableDef 已经在 getExternalWithColListProject / bind_load.go 里被裁成了只包含真实目标列的 schema，而 @var 这种输入字段不会出现在这个 tableDef 里。

结果就是：实际输入行里明明还有额外字段，新的统计却只按目标列宽来算，rowSize 会被明显低估，进而把 rowCount / Cost / Outcnt / BlockNum 系统性放大。这个路径不是理论上的，仓库里现有用例就有：test/distributed/cases/load_data/load_data.sql 里多处都在测 (@col1, col2) / (col1, @col2)。

对这类 LOAD，执行路径阈值会被更早打穿，可能把本来不该进 multi-CN 的任务提前推到 multi-CN。也就是说，这次改动把“按真实输入行宽估算”的目标，在带 @var 的 column list 场景下又重新打偏了。

看了最新更新后，前面 BlockNum 的 off-by-one 和 inline CSV 少算换行这两个点已经修掉了，但我还看到两个残留问题：

1. IGNORE n LINES 的首行采样可能仍然读到 header
   现在 estimateLoadRowsizeFromFirstLine 会按传入的 offset 去读首行做 rowSize 估算，但 offset = IgnoredLines(...) 只在 stmt.Param.Tail.IgnoredLines > 0 && stmt.Param.Parallel && noCompress && !stmt.Param.Local 时才会计算。也就是说，只要这条 LOAD 一开始没有开 Parallel，即使声明了 IGNORE 1 LINES，rowSize 采样仍然会从文件头开始，拿到 header 而不是首条数据行。

   这里的 stats 仍然会影响 GetExecType() 和 Cost * Rowsize 的并行度估算，所以这不是纯测试问题。建议把 header offset 的计算从 Parallel 条件里解耦，或者让采样逻辑自己跳过 ignored lines。

2. 文件被不必要地排除在首行采样之外
   estimateLoadRowsizeFromFirstLine 现在要求 loadLinesTerminatedBy(param) == "\n"，这会把显式 LINES TERMINATED BY \r\n 的 CSV 直接打回 schema fallback。\n\n 但 readExternalFirstLineSize 本身就是按 ReadString(n) 读的，天然可以把 \r\n 一起算进来；而且仓库里现有 LOAD DATA case 也明确支持 \r\n。所以这条 gate 会让一类常见文本文件继续落在偏差更大的 schema 估算上，和这次 PR 想修正的方向不一致。